1
2
следующий
Нет.
JSON - это только данные, и если вы добавите комментарий, это тоже будут данные.
У вас может быть назначенный элемент данных под названием «_comment» (или что-то в этом роде), который следует игнорировать приложениями, использующими данные JSON.
Вероятно, вам было бы лучше иметь комментарий в процессах, которые генерируют / получают JSON, поскольку они должны знать, какие данные JSON будут заранее, или, по крайней мере, их структуру.
Но если вы решили:
{
"_comment": "здесь идет текст комментария ...",
"глоссарий": {
"title": "пример глоссария",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
«ID»: «SGML»,
«SortAs»: «SGML»,
"GlossTerm": "Стандартный обобщенный язык разметки",
«Акроним»: «SGML»,
«Аббревиатура»: «ISO 8879: 1986»,
"GlossDef": {
"para": "Язык мета-разметки, используемый для создания языков разметки, таких как DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "разметка"
}
}
}
}
}
|
Нет, комментарии формы //… или / *… * / не допускаются в JSON. Этот ответ основан на:
https://www.json.org
RFC 4627:
Тип носителя application / json для нотации объектов JavaScript (JSON)
RFC 8259 Формат обмена данными JavaScript Object Notation (JSON) (заменяет RFC 4627, 7158, 7159)
|
Включите комментарии, если хотите; удалите их с помощью минификатора перед синтаксическим анализом или передачей.
Я только что выпустил JSON.minify (), который удаляет комментарии и пробелы из блока JSON и делает его действительным JSON, который можно анализировать. Итак, вы можете использовать это как:
JSON.parse (JSON.minify (my_str));
Когда я его выпустил, я получил огромное количество людей, не согласных даже с самой идеей, поэтому я решил, что напишу подробный пост в блоге о том, почему комментарии имеют смысл в JSON. Он включает в себя этот замечательный комментарий создателя JSON:
Предположим, вы используете JSON для хранения файлов конфигурации, которые хотите пометить. Вставьте все комментарии, которые вам нравятся. Затем пропустите его через JSMin, прежде чем передать его парсеру JSON. - Дуглас Крокфорд, 2012 г.
Надеюсь, это поможет тем, кто не согласен с тем, почему JSON.minify () может быть полезен.
|
Комментарии были удалены из JSON по дизайну.
Я удалил комментарии из JSON, потому что видел, что люди использовали их для хранения директив синтаксического анализа, что привело бы к нарушению взаимодействия. Я знаю, что некоторых людей огорчает отсутствие комментариев, но этого не должно быть.
Предположим, вы используете JSON для хранения файлов конфигурации, которые хотите аннотировать. Вставьте все комментарии, которые вам нравятся. Затем пропустите его через JSMin, прежде чем передать его парсеру JSON.
Источник: публичное заявление Дугласа Крокфорда в Google+.
|
JSON не поддерживает комментарии. Он также никогда не предназначался для использования в файлах конфигурации, в которых потребуются комментарии.
Hjson - это формат файла конфигурации для людей. Упрощенный синтаксис, меньше ошибок, больше комментариев.
См. Hjson.github.io для библиотек JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ и C #.
|
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: ВАША ГАРАНТИЯ НЕДЕЙСТВИТЕЛЬНА
Как уже отмечалось, этот хакер использует реализацию спецификации. Не все парсеры JSON поймут этот тип JSON. В частности, задыхаются потоковые парсеры.
Это интересное любопытство, но вы действительно не должны использовать его ни для чего. Ниже оригинальный ответ.
Я нашел небольшой прием, позволяющий размещать комментарии в файле JSON, который не повлияет на синтаксический анализ или каким-либо образом изменить представляемые данные.
Похоже, что при объявлении литерала объекта вы можете указать два значения с одним и тем же ключом, и последнее имеет приоритет. Вы не поверите, но оказывается, что парсеры JSON работают точно так же. Таким образом, мы можем использовать это для создания комментариев в исходном JSON, которые не будут присутствовать в представлении анализируемого объекта.
({a: 1, a: 2});
// => Объект {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Length;
// => 1
Если мы применим этот метод, ваш закомментированный файл JSON может выглядеть следующим образом:
{
"api_host": "Имя хоста вашего сервера API. Вы также можете указать порт.",
"api_host": "hodorhodor.com",
"retry_interval": "Интервал в секундах между повторными попытками неудачных вызовов API",
"retry_interval": 10,
"auth_token": "Токен аутентификации. Он доступен на панели инструментов разработчика в разделе" Настройки "",
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"избранное_numbers": "Массив, содержащий мои самые любимые числа",
"избранное_числа": [19, 13, 53]
}
Приведенный выше код является допустимым JSON. Если вы его проанализируете, вы получите такой объект:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"избранное_числа": [19,13,53]
}
Это означает, что комментариев нет и у них не будет странных побочных эффектов.
Удачного взлома!
|
Рассмотрите возможность использования YAML. Это почти надмножество JSON (практически весь действительный JSON - это действительный YAML), и он позволяет комментарии.
|
Вы не можете. По крайней мере, это мой опыт после беглого взгляда на json.org.
JSON имеет свой синтаксисвизуализируется на этой странице. Нет никаких заметок о комментариях.
|
Комментарии не являются официальным стандартом, хотя некоторые парсеры поддерживают комментарии в стиле C ++. Я использую JsonCpp. В примерах есть такой:
// Параметры конфигурации
{
// Кодировка по умолчанию для текста
"кодировка": "UTF-8",
// Плагины загружаются при запуске
"плагины": [
"питон",
"c ++",
"Рубин"
],
// Размер отступа табуляции
"indent": {"length": 3, "use_space": true}
}
jsonlint не проверяет это. Таким образом, комментарии являются расширением, специфичным для парсера, а не стандартным.
Другой парсер - JSON5.
Альтернатива JSON TOML.
Еще одна альтернатива - jsonc.
В последней версии nlohmann / json есть дополнительная поддержка игнорирования комментариев при синтаксическом анализе.
|
Вместо этого вам следует написать схему JSON. Схема JSON в настоящее время является предлагаемым проектом спецификации Интернета. Помимо документации, схему также можно использовать для проверки ваших данных JSON.
Пример:
{
"description": "Человек",
"тип": "объект",
"свойства":
{
"название":
{
"тип": "строка"
},
"возраст":
{
"тип": "целое число",
«максимум»: 125
}
}
}
Вы можете предоставить документацию, используя атрибут схемы описания.
|
Если вы используете Джексона в качестве парсера JSON, вы можете разрешить комментарии следующим образом:
ObjectMapper mapper = новый ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, true);
Тогда у вас могут быть такие комментарии:
{
key: "значение" // Комментарий
}
И вы также можете иметь комментарии, начинающиеся с #, установив:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, true);
Но в целом (как уже было сказано ранее) спецификация не допускает комментариев.
|
Вот что я нашел в документации Google Firebase, которая позволяет добавлять комментарии в JSON:
{
"//": "Некоторые браузеры будут использовать это для включения push-уведомлений.",
"//": "Он одинаков для всех проектов, это не идентификатор отправителя вашего проекта",
"gcm_sender_id": "1234567890"
}
|
Нет. JSON использовался для поддержки комментариев, но ими злоупотребляли и они были удалены из стандарта.
От создателя JSON:
Я удалил комментарии из JSON, потому что видел, что люди использовали их для хранения директив синтаксического анализа, что привело бы к нарушению взаимодействия. Я знаю, что некоторых людей огорчает отсутствие комментариев, но этого не должно быть. - Дуглас Крокфорд, 2012 г.
Официальный сайт JSON находится на JSON.org. JSON определен как стандарт ECMA International. Всегда существует процесс прошения о пересмотре стандартов. Вряд ли аннотации будут добавлены в стандарт JSON по нескольким причинам.
JSON по своему замыслу представляет собой легко реверсивную (анализируемую человеком) альтернативу XML. Он упрощен до такой степени, что аннотации не нужны. Это даже не язык разметки. Цель - стабильность и совместимость.
Любой, кто понимает взаимосвязь объектной ориентации «имеет-а», может понять любую структуру JSON - в этом весь смысл. Это просто ориентированный ациклический граф (DAG) с тегами узлов (парами ключ / значение), который представляет собой почти универсальную структуру данных.
Эта единственная необходимая аннотация может быть такой: «// Это теги DAG». Имена клавиш могут быть настолько информативными, насколько это необходимо, что допускает произвольную семантическую арность.
Любая платформа может анализировать JSON с помощью всего нескольких строк кода. XML требует сложных объектно-ориентированных библиотек, которые не работают на многих платформах.
Аннотации только сделают JSON менее совместимым. Больше просто нечего добавить, если только вам действительно не нужен язык разметки (XML), и вам все равно, легко ли анализируются ваши сохраненные данные.
НО, как заметил и создатель JSON, для комментариев всегда была поддержка конвейера JS:
Вставьте все комментарии, которые вам нравятся.
Затем пропустите его через JSMin, прежде чем передать его парсеру JSON. - Дуглас Крокфорд, 2012 г.
|
Если ваш текстовый файл, представляющий собой строку JSON, будет прочитан какой-либо программой, насколько сложно будет удалить комментарии в стиле C или C ++ перед его использованием?
Ответ: Это будет однострочный. Если вы это сделаете, файлы JSON можно будет использовать в качестве файлов конфигурации.
|
Если вы используете библиотеку Newtonsoft.Json с ASP.NET для чтения / десериализации, вы можете использовать комментарии в содержимом JSON:
// "имя": "строка"
// "id": int
или
/* Это
пример комментария * /
PS: Однострочные комментарии поддерживаются только в 6+ версиях Newtonsoft Json.
Дополнительное примечание для людей, которые не могут мыслить нестандартно: я использую формат JSON для основных настроек в созданном мной веб-приложении ASP.NET. Я читаю файл, конвертирую в объект настроек с помощью библиотеки Newtonsoft и использую при необходимости.
Я предпочитаю писать комментарии о каждой отдельной настройке в самом файле JSON, и меня действительно не волнует целостность формата JSON, если библиотека, которую я использую, подходит для этого.
Я думаю, что это «более простой для использования / понимания» способ, чем создание отдельного файла settings.README и объяснение в нем настроек.
Если у вас есть проблемы с таким использованием; извините, джинн из лампы. Люди найдут другие способы использованияФормат JSON, и вы ничего не можете с этим поделать.
|
Идея JSON состоит в том, чтобы обеспечить простой обмен данными между приложениями. Обычно они основаны на Интернете, а язык - JavaScript.
На самом деле это не позволяет использовать комментарии как таковые, однако передача комментария в качестве одной из пар имя / значение в данных, безусловно, сработает, хотя эти данные, очевидно, должны игнорироваться или обрабатываться специально с помощью кода синтаксического анализа.
При этом не предполагается, что файл JSON должен содержать комментарии в традиционном смысле. Это должны быть просто данные.
Посетите веб-сайт JSON для получения более подробной информации.
|
JSON изначально не поддерживает комментарии, но вы можете создать свой собственный декодер или, по крайней мере, препроцессор, чтобы вырезать комментарии, это прекрасно (пока вы просто игнорируете комментарии и не используете их, чтобы указать, как ваше приложение должно обрабатывать данные JSON ).
JSON не имеет комментариев. Кодировщик JSON НЕ ДОЛЖЕН выводить комментарии.
Декодер JSON МОЖЕТ принимать и игнорировать комментарии.
Комментарии никогда не должны использоваться для передачи чего-либо значимого. То есть
для чего нужен JSON.
См .: Дуглас Крокфорд, автор спецификации JSON.
|
Я просто сталкиваюсь с этим для файлов конфигурации. Я не хочу использовать XML (подробный, графический, некрасивый, трудно читаемый) или формат «ini» (без иерархии, без реального стандарта и т. Д.) Или формат «Свойства» Java (например, .ini).
JSON может делать все, что они могут, но он менее подробный и более удобочитаемый, а парсеры просты и повсеместны на многих языках. Это просто дерево данных. Но внеполосные комментарии часто необходимы для документирования конфигураций "по умолчанию" и т.п. Конфигурации никогда не должны быть «полными документами», а должны быть деревьями сохраненных данных, которые при необходимости могут быть прочитаны человеком.
Я предполагаю, что можно использовать "#": "comment" для "действительного" JSON.
|
Это зависит от вашей библиотеки JSON. Json.NET поддерживает комментарии в стиле JavaScript, / * комментарий * /.
См. Еще один вопрос о переполнении стека.
|
JSON имеет большой смысл для файлов конфигурации и другого локального использования, поскольку он повсеместен и намного проще, чем XML.
Если у людей есть веские причины против использования комментариев в JSON при передаче данных (независимо от того, действительны они или нет), то, возможно, JSON можно разделить на два:
JSON-COM: JSON на проводе или правила, применяемые при передаче данных JSON.
JSON-DOC: документ JSON или JSON в файлах или локально. Правила, определяющие действительный документ JSON.
JSON-DOC допускает комментарии, и могут существовать другие незначительные различия, такие как обработка пробелов. Парсеры могут легко конвертировать из одной спецификации в другую.
Что касается замечания Дугласа Крокфорда по этому поводу (на которое ссылается @Artur Czajka)
Предположим, вы используете JSON для хранения файлов конфигурации, которые хотите аннотировать. Вставьте все комментарии, которые вам нравятся. Затем пропустите его через JSMin, прежде чем передать его парсеру JSON.
Мы говорим об общей проблеме с файлом конфигурации (кросс-язык / платформа), и он отвечает специальной утилитой JS!
Конечно, минимизация JSON может быть реализована на любом языке,
но стандартизируйте это, чтобы оно стало повсеместным в парсерах на всех языках и платформах, чтобы люди перестали тратить свое время на отсутствие этой функции, потому что у них есть хорошие варианты ее использования, поиск проблемы на онлайн-форумах и получение людей, говорящих им, что это плохая идея или предлагая легко реализовать удаление комментариев из текстовых файлов.
Другой вопрос - это совместимость. Предположим, у вас есть библиотека, API или любая подсистема, с которой связаны файлы конфигурации или данных. И эта подсистема
для доступа с разных языков. Тогда вы говорите людям: кстати
не забудьте вырезать комментарии из файлов JSON перед их передачей парсеру!
|
Если вы используете JSON5, вы можете включать комментарии.
JSON5 - это предлагаемое расширение JSON, цель которого - облегчить людям писать и поддерживать вручную. Это достигается за счет добавления некоторых минимальных синтаксических функций непосредственно из ECMAScript 5.
|
Набор инструментов Dojo Toolkit JavaScript (по крайней мере, начиная с версии 1.4) позволяет включать комментарии в ваш JSON. Комментарии могут иметь формат / * * /. Dojo Toolkit использует JSON через вызов dojo.xhrGet ().
Другие инструменты JavaScript могут работать аналогичным образом.
Это может быть полезно при экспериментировании с альтернативными структурами данных (или даже списками данных) перед выбором окончательного варианта.
|
JSON не является протоколом с фреймами. Это свободный от языка формат. Таким образом, формат комментария для JSON не определен.
Как предлагали многие, есть некоторые уловки, например, дублирование ключей или определенный ключ _comment, который вы можете использовать. Тебе решать.
|
Вы можете иметь комментарии в JSONP, но не в чистом JSON. Я только что потратил час, пытаясь заставить мою программу работать с этим примером из Highcharts: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?
Если вы перейдете по ссылке, то увидите
? (/ * AAPLисторические данные OHLC из Google Finance API * /
[
/ * Май 2006 г. * /
[1147651200000,67,79],
[1147737600000,64,98],
...
[1368057600000,456,77],
[1368144000000,452,97]
]);
Поскольку у меня был аналогичный файл в моей локальной папке, проблем с политикой одинакового происхождения не было, поэтому я решил использовать чистый JSON ... и, конечно же, $ .getJSON молча терпел неудачу из-за комментариев.
В конце концов я просто отправил ручной HTTP-запрос по указанному выше адресу и понял, что тип содержимого был text / javascript, поскольку JSONP возвращает чистый JavaScript. В этом случае комментарии разрешены. Но мое приложение вернуло application / json типа содержимого, поэтому мне пришлось удалить комментарии.
|
Это вопрос "можете ли вы". И вот ответ «да».
Нет, вы не должны использовать повторяющиеся элементы объекта для вставки данных побочного канала в кодировку JSON. (См. «Имена внутри объекта ДОЛЖНЫ быть уникальными» в RFC).
И да, вы можете вставить комментарии вокруг JSON, которые вы могли бы проанализировать.
Но если вам нужен способ вставки и извлечения произвольных данных побочного канала в действительный JSON, вот ответ. Мы пользуемся преимуществом неуникального представления данных в кодировке JSON. Это разрешено * во втором разделе RFC в разделе «Пробелы разрешены до или после любого из шести структурных символов».
* В RFC указано только, что «пробелы разрешены до или после любого из шести структурных символов», без явного упоминания строк, чисел, «ложь», «истина» и «ноль». Это упущение игнорируется во ВСЕХ реализациях.
Во-первых, канонизируйте свой JSON, уменьшив его:
$ jsonMin = json_encode (json_decode ($ json));
Затем закодируйте свой комментарий в двоичном формате:
$ hex = распаковать ('H *', $ комментарий);
$ commentBinary = base_convert ($ hex [1], 16, 2);
Затем введите свой двоичный файл:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Вот ваш результат:
$ jsonWithComment = $ steg. $ jsonMin;
|
Отказ от ответственности: это глупо
На самом деле есть способ добавлять комментарии и оставаться в рамках спецификации (дополнительный парсер не требуется). Однако это не приведет к появлению удобочитаемых комментариев без какого-либо анализа.
Вы можете злоупотребить следующим:
Незначительные пробелы разрешены до или после любого токена.
Пробел - это любая последовательность одного или нескольких из следующего кода
точки: табуляция символов (U + 0009), перевод строки (U + 000A), каретка
return (U + 000D) и пробел (U + 0020).
Хакерским способом вы можете злоупотребить этим, чтобы добавить комментарий. Например: начинайте и заканчивайте свой комментарий табуляцией. Закодируйте комментарий в base3 и используйте другие символы пробела для их представления. Например.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(привет, основание три в ASCII) Но вместо 0 используйте пробел, для 1 используйте перевод строки и для 2 используйте возврат каретки.
Это просто оставит вам много нечитаемых пробелов (если вы не создадите плагин IDE для кодирования / декодирования его на лету).
Я даже не пробовал это по понятным причинам, да и вам тоже.
|
Сам по себе JSON не допускает комментариев. Рассуждения совершенно глупые, потому что вы можете использовать сам JSON для создания комментариев, что полностью устраняет рассуждения и загружает пространство данных парсера без всякой уважительной причины для точно такого же результата и потенциальных проблем, таких как: JSON файл с комментариями.
Если вы попытаетесь вставить комментарии (например, используя // или / * * / или #), то некоторые парсеры не сработают, потому что это строго не
в рамках спецификации JSON. Так что вам никогда не следует этого делать.
Вот, например, где моя система обработки изображений сохранила нотации изображений и некоторую базовую отформатированную (комментарии) информацию, относящуюся к ним (внизу):
{
«Обозначения»: [
{
"anchorX": 333,
«якорь»: 265, г.
"areaMode": "Эллипс",
"extensionX": 356,
"extensionY": 294,
«непрозрачность»: 0,5,
"text": "Эллиптическая область сверху",
"textX": 333,
"textY": 265,
"title": "Обозначение 1"
},
{
"anchorX": 87,
«якорь»: 385, г.
"areaMode": "Прямоугольник",
"extensionX": 109,
"extensionY": 412,
«непрозрачность»: 0,5,
"text": "Прямоугольная область \ не снизу",
"textX": 98,
"textY": 385,
"title": "Обозначение 2"
},
{
"anchorX": 69,
«якорь»: 104,
"areaMode": "Многоугольник",
"extensionX": 102,
"extensionY": 136,
«непрозрачность»: 0,5,
"pointList": [
{
«i»: 0,
«х»: 83,
«y»: 104
},
{
«i»: 1,
«x»: 69,
«y»: 136
},
{
«i»: 2,
«х»: 102,
«y»: 132
},
{
«i»: 3,
«х»: 83,
«y»: 104
}
],
"text": "Простой многоугольник",
«textX»: 85,
"textY": 104,
"title": "Обозначение 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "Данные обозначения изображения JSON:",
"c02": "-------------------------",
"c03": "",
"c04": "Эти данные содержат обозначения изображений и связанные области",
"c05": "информация о выборе, которая предоставляет средства для",
"c06": "галерея изображений для отображения обозначений в виде эллипсов,",
"c07": "указатели прямоугольной, многоугольной или произвольной формы",
"c08": "поверх изображения, отображаемого посетителю галереи.",
"c09": "",
"c10": "Все позиции X и Y указаны на изображении.Космос. Изображение",
"c11": "разрешение задается как imageXW и imageYW, что",
"c12": "вы используете, чтобы масштабировать области обозначений до нужного размера",
"c13": "расположение и размеры для отображения изображения",
"c14": "независимо от масштаба.",
"c15": "",
"c16": "Для эллипсов привязкой является центр эллипса",
"c17": "а экстенты - это радиусы X и Y соответственно.",
"c18": "",
"c19": "Для прямоугольников привязкой является верхний левый угол, а",
"c20": "экстенты - нижний правый.",
"c21": "",
"c22": "Для режимов Freehand и Polygon area, pointList",
"c23": "содержит серию пронумерованных точек XY. Если область",
"c24": "закрывается, последняя точка будет такой же, как",
"c25": "во-первых, поэтому вам нужно только рисовать",
"c26": "линии между точками в списке. Якорь и экстент",
"c27": "устанавливаются вверху слева и внизу справа от указанного",
"c28": "область и может использоваться как упрощенный прямоугольник",
"c29": "определять положение наведения курсора мыши на эти типы",
"c30": "площадей.",
"c31": "",
"c32": "Позиции textx и texty обеспечивают базовое позиционирование",
"c33": "информация, которая поможет вам найти текстовую информацию",
"c34": "в разумном месте, связанном с районом",
"c35": "индикация.",
"c36": "",
«c37»: «Непрозрачность - это значение от 0 до 1, где 0,5 представляет»,
"c38": "50% непрозрачный фон, а 1.0 - полностью непрозрачный",
"c39": "backdrop. Рекомендуем рисовать области",
"c40": "только если пользователь наводит указатель на изображение",
"c41": "и чтобы текст, связанный с областями, был нарисован",
"c42": "только если пользователь наводит указатель на указанное",
"c43": "регион".
}
}
|
В нашем проекте мы используем strip-json-comments. Он поддерживает что-то вроде:
/ *
* Описание
* /
{
// радуги
"единорог": / * ❤ * / "торт"
}
Просто npm install --save strip-json-comments, чтобы установить и использовать его так:
var strip_json_comments = require ('strip-json-comments')
var json = '{/ * радуги * / "единорог": "торт"}';
JSON.parse (strip_json_comments (json));
// => {единорог: 'торт'}
|
В моем случае мне нужно использовать комментарии для целей отладки прямо перед выводом структуры JSON. Поэтому я решил использовать отладочную информацию в заголовке HTTP, чтобы не нарушить работу клиента:
header ("My-Json-Comment: Да, я знаю, что это обходной путь ;-)");
|
Чтобы разрезать элемент JSON на части, я добавляю строки «фиктивного комментария»:
{
«############################»: «Часть 1»,
"данные1": "значение1",
"данные2": "значение2",
"#############################" : "Часть 2",
"данные4": "значение3",
"данные3": "значение4"
}
|
1
2
следующий
Весьма активный вопрос. Заработайте 10 репутации, чтобы ответить на этот вопрос. Требование репутации помогает защитить этот вопрос от спама и отсутствия ответов.
Не тот ответ, который вы ищете? Просмотрите другие вопросы с тегами json comments или задайте свой вопрос.